docs: make README product-first and integrator-friendly - #160

Outcome

Refresh Orgmetra's protected-develop landing page around its code-current HRIS/HCM responsibility instead of mixing the product story with stale active-PR state.

• lead with evidence-centered HRIS/HCM value and buyer-visible jobs;
• keep Person / Employment / Organization / Job / Position / Assignment distinctions explicit;
• provide a copy-paste validation path aligned with Foundation CI (Node 24 / Python 3.14, npm ci, npm run validate);
• explain federated integration ownership without presenting planned boundaries as shipped behavior;
• make protected-branch versus active-PR authority explicit;
• provide a navigable documentation map and the existing Apache-2.0 / NOTICE boundary.

Evidence and licensing

The README is grounded in docs/PRD.md, ARCHITECTURE.md, docs/TRACEABILITY.md, package metadata, repository workflows, and the existing root LICENSE/NOTICE. The Apache-2.0 grant applies to Orgmetra-owned source; third-party packages and external systems retain their own terms. No certification, production deployment, employment-decision authority, or customer claim is invented.

Repair chain

Fresh hosted validation first proved that the README manifest record was stale; the branch resealed it from the exact README bytes instead of weakening repository integrity. Fresh review then found an unsealed docs/index.md public landing candidate outside the validator's closed required-artifact set. That candidate was removed rather than widening the public surface without a publication/integrity contract, leaving the governed root README as the landing source.

Current README maturity labels distinguish protected-main implementation, accepted architecture, and planned/active-PR boundaries, including separate Psychometrics Commons versus fast-mlsirm responsibilities. Validation scope is explicit so npm run validate is not represented as complete PostgreSQL/package verification.

The README also separates Orgmetra-local controls/trust-boundary documentation from vulnerability disclosure. Suspected vulnerabilities are directed to the organization-owned ContextualWisdomLab/.github@main:SECURITY.md reporting policy. No claim is made that repository-private vulnerability reporting is enabled unless live repository evidence establishes it.

The feature snapshot's manifest seal matches its README bytes after that reporting repair (sha256=10f4ad947efee5e54166cd31e18cf30d34489b7c13fd05cb565363c1a86271c5, 9,344 bytes, 141 lines). That seal is historical source evidence only and must be regenerated after protected-parent reconciliation.

Live authority and lifecycle repair

• exact feature head: a7d9e1aa0fb6e007e3b0cb8f495f4d4dc512e9e8;
• PR recorded base snapshot: develop@9e3e4847510e1e612b48474ba42b177b8ed824df;
• current protected truth: develop@eb9757f8649aaad026a9865508d9aad50c1a7a4f;
• live state: open · Draft · currently non-mergeable after GitHub recomputation.

The earlier non-Draft/mergeable wording is superseded. Protected develop has advanced through #161 repository-quality workflow consolidation, so this README/manifest lane must reconcile that protected truth rather than overwrite it with either historical tree. A conflict or non-mergeable result is a repair finding, not a close condition.

Historical exact-source evidence on a7d9e1a... remains non-transferable: Foundation CI 33586731896, Recovery Rehearsal 33586731888, and Job-Analysis API Quality 33586731749 were terminal-success; Security Scan 33586731818 failed at Dependency Review support; SAST 33586731773 was non-terminal at the recorded snapshot. Those results cannot authorize a reconciled head.

Required non-force reconciliation

Preserve the valid product-first README content, non-force adopt the then-current protected develop, and resolve README/provenance conflicts semantically. Do not resurrect workflows removed by #161. After the final README bytes are chosen, regenerate manifest.json from those exact bytes rather than selecting either stale manifest wholesale. Then reacquire every applicable exact-head Foundation/recovery/Security/SAST/CodeQL/review gate before Ready.

Current diff intent remains README plus deterministic manifest only; no runtime, dependency, schema, API, workflow, release, certification, employment-decision, UI, or ecosystem-ownership behavior is claimed by this lane.

Do not force-rebase, self-approve, use routine administrator bypass, enable auto-merge on stale evidence, add no-op retrigger churn, transfer predecessor evidence, or treat temporary mergeability as authorization.